IBIS Macromodel Task Group Meeting date: 21 July 2020 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Todd Bermensolo Stephen Slater Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Randy to create a BIRD draft for the Component_Name and Signal_Name Reserved Parameters proposal. - Done. - Zhiping to email links to past Summit presentations and info about his upcoming EMC SI+PI conference presentation to ATM. - In progress, mail will be sent shortly after this meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 14 meeting. Randy moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: Component_Name and Signal_Name Reserved Parameters BIRD draft: Randy shared the new BIRD draft and noted that it was largely the same as the previous week's proposal, but it was in official BIRD draft form. It introduces two new AMI Reserved parameters, Component_Name and Signal_Name, that are Format String and Type In. In the Definition of the Issue: section, Randy describes the possibility of the executable model maintaining a list or look-up table based on the Component name and signal_name from the IBIS file. The combination of the two could form a unique identifier for a particular Tx or Rx on the die, and the executable model could use the look-up table to store buffer-specific characteristics, such as DQ to DQS delay. This would allow one executable model to fully model multiple buffers. The EDA tool would pass the Component name and signal_name information in via the new parameters. Randy noted that he added a new sentence in the Usage Rules: sections explaining that a tool should pass in "NA" if the simulation setup is such that the tool doesn't know the Component name or signal name. He had also added examples using Value and Default. Randy said he and Curtis had discussed the issue, and he asked for thoughts on the "default" value in the file. Curtis said he had proposed to Randy that we might consider putting a meaningful default value in the .ami file (in the Value or Default). This might give older tools that don't recognize the parameter a better chance of passing in a reasonable value. Perhaps we simply put "NA" in the Value in the .ami file, in addition to the statement that the tool should pass in "NA" if it doesn't know the values of the Component name or signal_name. Bob objected to the use of "NA", and said it is expressly illegal for a [Component] to be named "NA". Radek said that made "NA" a good choice for use with the Component_Name parameter. Arpad noted that "NA" is a valid name for a signal_name, and he suggested the tool should instead pass in an empty string ("") if it doesn't know the Component_Name or Signal_Name. Randy made the change from "NA" to "". Arpad said he didn't like the example with a Default value of "Memory_x8", as he didn't think it was good to have a meaningful value in the .ami file. The group decided the entire Default example was redundant, since Value and Default are essentially interchangeable in this case. Randy removed it. Randy asked if it was necessary to mention that these new parameters would be passed in to AMI_Resolve as well as AMI_Init. Radek suggested the text should continue to include AMI_Resolve, as the values of these two new parameters might affect AMI_Resolve's decisions about other Dep parameters. Randy left the mention of AMI_Resolve intact. Ambrish and Arpad asked if we should state that the model should act as if it had recieved the value ("") if the EDA tool doesn't pass in these parameters at all. Randy said that we don't explicitly state what the model should do if EDA tools choose to ignore other parameters. Radek and Curtis noted that the specification explicitly states that the EDA tools should pass in the values of each and every In and InOut parameter. In 10.3.6, page 222: The EDA tool shall pass a string to the executable model through the AMI_parameters_in argument. This string shall contain all of the leaf-formatted Usage In and Usage InOut AMI parameters if there are any defined in the .ami file. So, even if in practice some parameters might not be sent in certain situations (e.g., older tools that don't recognize a new parameter), we don't want to codify that in the specification. Randy said he would send out a modified draft. Arpad said he would keep it on the agenda for the next meeting. Supporting PI modeling/simulation in IBIS: Zhiping said he had nothing new to present, and he encouraged any questions or feedback related to his ideas about adding PI modeling information to IBIS. Zhiping asked if there were any policies or requirements related to inviting other PI people to the ATM meetings. Arpad said the discussions are free and open to anyone, they just wouldn't be able to vote if they weren't IBIS members. Topic bin list: Randy noted the longstanding topic "Fix all the referencing problems in the current specification (after Randy's C_comp proposal and BIRD189 are done)". Randy asked if anyone was interested in tackling the topic. Arpad asked if BIRD181.1 is still the place to tackle the referencing issues. Bob said that it is, and that it addresses references, terminals, the meaning of various voltage ranges, etc., and introduces a SPICE like syntax for indicating the potential difference between two nodes. Arpad noted that it had been a recent topic on the SIlist, and he had seen package models formulated with only a 2 port S-parameter, i.e., two terminals for the VCC path and no separate path for VSS, instead of the 4-port partial loop models we specify in IBIS. Bob said in practice we can define what we want, but it may be a subset of what the industry at large tries to do. Bob noted that certain assumptions, including ideal ground, were built in to early work in Chapter 9, Data Derivation. However, if we understand the original intent of the data derivation, we can explicitly generalize the assumptions for modern application scenarios. It's just that it will be a long arduous process to get agreement on the generalizations and make the editorial changes. Randy said the answer to his original question boils down to: Do we finally want to deal with BIRD181? Randy suggested that we could leave it alone for now unless someone wants to lead the effort. We have plenty of other things to work on. - Ambrish: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Randy to send out a modified version of the Component_Name and Signal_Name BIRD draft. ------------- Next meeting: 28 July 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives